Page history of 애자일 선언 다시보기

그동안 애자일에 대해 쓰고 싶은 글이 하나 있었다. 애자일의 함정 같은 중2병 돋는 제목을 붙이고, 애자일의 진짜 단점들과 반론들을 써보려고 했다. 근데 요즘 여기저기 다양한 회사와 사람들을 만나면서 아직 한국은 애자일의 단점 같은 거 논할 때가 아니라는 생각이 들었다. 심지어 애자일 사례 발표라고 하는 것도 내용을 보면 애자일과 무관하거나, 심지어 애자일에 반하는 내용이 많았다. xper 메일링에도 애자일에 대한 오해로 가득하고, 애자일을 제대로 이해하고 있다고 할 만한 사람은 극소수다. 게다가 그런 오해들은 점점 확산되고 있다. 

그래서 한 번쯤 애자일이 뭔지에 대해 짚어볼 필요가 있다는 생각이 들었다. 니가 뭔데 애자일이 뭔지 니 맘대로 정의하냐고? 물론, 내 맘대로 정의할 생각은 없다. 오히려 그 반대로 아무도 제발 애자일을 맘대로 정의하지 말았으면 좋겠다. 내가 말하고 싶은 것은 애자일이라는 단어를 용어로 정착시킨 사람들의 정의를 그대로 사용하자는 것이다.

애자일 선언

2001년 2월에 XP, 스크럼 등을 대표하는 선지자들이 모여서 공통점을 모아 애자일 선언이라는 걸 발표했다. 이것이 애자일이 용어로써 자리잡게 된 시초다. http://agilemanifesto.org/를 통해서 전문을 볼 수 있고, 선언에 참여한 저자들, 선언의 배경 등에 대한 설명도 있다. 다행히 한국어 번역도 있다. 번역하기 어려운 내용임에도 꽤 잘된 번역이라고 생각하지만, 약간의 거리감이 있는 것 같아서 여기서는 영문을 차용해서 이야기하려고 한다. 애자일 선언은 네 문장의 가치 선언과, 이를 부연하는 12개의 원칙으로 구성되어 있다.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

over 오른쪽에 서술된 것도 중요하게 생각하지만 굵은 글씨로 왼쪽에 서술된 것에 더 가치를 두자는 것이 애자일 선언이다. 그럼 일단 이것부터 하나하나 뜯어보자.

Individuals and interactions over processes and tools

개인과 상호작용을 프로세스와 도구보다 중시한다는 것이다. 추상적인 말 같지만 의외로 실제 사례로 이야기하기 쉽다. 우선 individuals, 개인이 뜻하는 바는 무엇일까? 흔히 한국사람들이 하는 이야기로 사람이 중요하다라는 표현이 있는데 그런 의미일까? 그럼 아마 people이라고 썼을 것이다. 굳이 individual이라는 단어를 쓰고, 프로세스나 도구에 대비시킨 것은 개인의 판단과 의사결정을 말하고 싶은 것이다. 관료주의 조직은 흔히 판단을 프로세스에 맡기려는 경향을 보인다. 실무자에게 결정권이 없고 의사결정은 위로위로 프로세스에 태운다. 사실 그렇게 프로세스에 태워도 누군가는 사람이 결정을 할 수 밖에 없는데도 뭔가 프로세스에 따라 결정을 내리면 더 안전하다고 생각한다. 그래서 개인의 판단보다 프로세스를 통한 결정이 중시된다. 애자일은 이것을 극복하고 개인에게 더 많은 것을 위임하기를 권하는 것이다.

구체적인 예를 들어보자. 테스트 커버리지가 60%를 넘겨야 한다는 규칙을 가진 조직이 있다고 가정해보자. 그런데 어느날 개발자 A는 개발을 하다가 유닛 테스트를 만들 필요가 전혀 없는 기능을 개발하게 되었다. 그런데 마침 소스 코드의 커버리지는 60%를 아주 약간 상회하는 수준이었고, 개발자 A가 해당 기능을 테스트 없이 추가하게 되면 바로 테스트 커버리지는 59%가 된다. 이런 상황에서 개발자 A가 자신의 개인 판단으로 테스트를 만들지 않기로 결정할 수 있다면 프로세스를 지키기 위해 무조건 테스트를 추가하는 것보다 더 애자일한 것이다. 여기서 규칙을 어겼다고 비난하지 않고 오히려 더 나아가 60%라는 규칙에 의심을 품을 기회로 삼고 거기에 대한 토론까지 진행한다면 아주 훌륭한 애자일 팀이다.

서버에 장애가 나서 서비스가 중단되었다. 개발자 B는 마침 이 문제가 코드 한 줄만 수정하면 되는 간단한 일임을 발견했다. 너무 명백한 문제라서 모든 팀원이 그 해법에 동의한다. 그래서 로컬에서 간단히 코드 수정해서 확인해본 후 바로 실 서버에 적용한다면 이 팀은 꽤 애자일한 팀이다. 그런데 곧이 곧대로 코드를 테스트 서버에도 올려서 QA에게 확인을 받고 15분이 걸리는 전체 회귀 테스트를 다 돌린 다음 실 서버에 배포한다면 이 팀은 그리 애자일한 팀이 아니다.

그러니까, 현장에서 문제를 가장 잘 이해하고 있는 개인의 판단이 정해진 프로세스를 넘어서거나 우회할 수 있다면 좀더 애자일한 것이다. 반대로 상황과 무관하게 늘 프로세스를 곧이 곧대로 지켜야 한다면 애자일하지 않은 것이다.

interaction, 상호작용이 의미하는 것은 뭘까? 이것은 아주 쉬운, 그리고 아주 흔하게 보이는 사례가 있다.

마케팅팀과 영업팀으로부터 늘 요구사항에 시달리는 개발팀이 있다. 그들은 불쑥 찾아와서 개발자의 집중을 방해하고는 요구사항을 마구 늘어놓고 돌아간다. 메일로도 요구사항들이 쏟아진다. 개발자는 일하기가 힘들어서 대책을 강구한다. 누군가 이슈 트래커라는 걸 쓰면 된다고 알려준다. 짜잔, JIRA를 도입했다. 이제부터 개발팀에 요청하실 일은 무조건 JIRA에 올려주세요. JIRA에 안 올리면 일은 하지 않을 것이고, JIRA에 올린 티켓이 적절한 우선순위를 배당 받으면 그 때 작업을 시작할 겁니다. 이제 개발팀에 직접 찾아오는 사람을 돌려보낼 겁니다.

개발자들은 이제 방해 받지 않게 되었고, 그저 우선순위대로 정렬된 티켓을 하나씩 가져와서 하기만 하면 되었다. 마케팅팀도 영업팀도 이제 자신들의 요구사항을 개발자가 까먹어서 안해주는 일은 사라졌다. 이제 모두가 행복해졌다.

이런 패턴은 정말 지겹도록 봐왔는데, 놀라운 것은 이것을 애자일한 방법으로 생각한다는 것이다. 하지만 이것은 명백히 interaction, 상호작용보다 프로세스와 도구를 중시하는 태도로, 애자일에서 지양해야 할 방법이다.